home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 729 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  9.1 KB
  1. Date: Sat, 9 Jul 1994 09:08:20 -0400 (EDT)
  2. Date: Fri, 8 Jul 94 23:17:45 EDT
  3. Subject: Gem List (fwd) from goemon
  4. Subject: Gem List
  5. Subject:  RE: Gem Listing (fwd)
  6. Subject:  Re: Gem Listing (fwd)
  7. Subject:  RE: Gem Listing (fwd)
  8. Date: Sat, 9 Jul 1994 09:08:20 -0400 (EDT)
  9. Mime-Version: 1.0
  10. Precedence: bulk
  11.  
  12. Forwarded message:
  13. >From goemon@venice.mps.ohio-state.edu Fri Jul  8 23:17:53 1994
  14. From: Goemon <goemon@venice.mps.ohio-state.edu>
  15. Message-Id: <9407090317.AA11185@venice.mps.ohio-state.edu>
  16. Subject: Gem List
  17. To: gem-list-approval@world.std.com
  18. Date: Fri, 8 Jul 94 23:17:45 EDT
  19.  
  20.  
  21. TO: gem-list@world.std.com
  22. Subject:  RE: Gem Listing (fwd)
  23.  
  24. David:
  25. ------
  26. > No, the point is that using the mouse events (in/out of
  27. > rectangles) is pretty difficult. Your code [sorry, this system
  28. > doesn't support quoting] is a busy loop which was what we were
  29. > trying to get away from.
  30.  
  31. Busy looping?  What do you call a "do { } while" ???  THAT'S a busy loop
  32. if I ever SAW one!
  33.  
  34. > I'd appreciate it if someone could
  35. > post a code fragment using rectangle events, I agree it shouldn't be too 
  36. > difficult just that I've never had chance to try!
  37.  
  38. Trust me, it's more difficult than what I posted, and it takes more time to
  39. use.  Why not just TRY my code out and see for yourself?  Speed difference
  40. is almost NIL.
  41.  
  42. > and I need to trigger an event as the mouse passes into or out of the inner 
  43. > rectangle.
  44.  
  45. Refer to programmers' manuals...  I know that MU_M1 and MU_M2 provide these,
  46. but since I never use this, I don't know.
  47.  
  48. -Ken Hollis
  49. -----
  50. Subject:  Re: Gem Listing (fwd)
  51.  
  52. Warwick:
  53. --------
  54. > Ken, I agree, that way is very easy to code.  The problem is whether it
  55. > is of sufficiently low cost to impose it as a standard for applications
  56. > to follow.
  57.  
  58. I don't quite understand what you mean by saying "low cost".  It's just about
  59. four lines of code that is easy to do.  It takes almost no time, because,
  60. it checks the object under the mouse.  Here's something that does almost
  61. EXACTLY the same thing as rectangle events:
  62.  
  63. /* Program start */
  64. /* Assume all variables are known by their names.  Pretty easy to understand,
  65.    or so I would hope. */
  66.    
  67. last_edit = 0;
  68. do {
  69.     /* Do your event loop thingie here */
  70.     object = objc_find(tree, mouse_x, mouse_y);
  71.     
  72.     if ((last_edit != object) && (object != -1)) {
  73.         last_edit = object;
  74.         if (tree[last_edit].ob_flags & EDITABLE)
  75.             graf_mouse(TEXT_CRSR, 0L);
  76.         else
  77.             graf_mouse(ARROW, 0L);
  78.     }
  79. } while(!(exitobject));
  80.  
  81. ( THIS IS EVEN FASTER THAN THE FIRST IDEA )
  82.  
  83. The ONLY way you can find out which object is under the mouse is by using
  84. objc_find.  There is absolutely no other way to get rectangles under the
  85. mouse without having to SAVE the physical dimensions of the rectangles,
  86. storing those in an array, and checking the array every time the mouse
  87. moves.  That's slower, and I think that's what SOME of you are trying to get
  88. at.  This is the FASTEST idea I can think of off the top of my head.  Bench-
  89. marking may prove faster.
  90.  
  91. >(1) is easy to code (thank you Ken), but an inefficient use of
  92. >    events, as if 5 multitasking programs do this, then for
  93. >    every motion of the mouse, each of those programs will
  94. >    be woken up and each will call objc_find.  In many cases,
  95. >    the objc_find will be very short, but it is still a system
  96. >    call for each application for every motion of the mouse.
  97.  
  98. Warwick, I don't think you understood me.  The only time the mouse will be
  99. checked is if the program is topped, or background activated.  It will not
  100. check the mouse otherwise.
  101.  
  102. If it's more difficult to code, why not use the method I explained earlier?
  103. Even E_GEM does this!
  104.  
  105. > But if all GEM libraries are the same, why would you change from one to
  106. > another?  GEM++ for example doesn't even use the Extended Object Types
  107. > byte.  It uses full parameterized object instantiations presribed in
  108. > the code, allowing any number of different types of object from sliders
  109. > to scrolling self-drawing objects.
  110.  
  111. That's the problem.  Not all GEM libraries are the same.  Why not use
  112. Extended Object Types?  They add functionality and make the resources look
  113. better.  That's the reason EObT's are there.
  114.  
  115. > What do you think Drag And Drop is for?  Exactly what sorts of messages
  116. > do you have in mind?  If I write a pair of apps that send each other messages,
  117. > they can use whatever protocol I want, as it is not a shared resource.
  118.  
  119. You're forgetting that Drag-and-drop is an application message!  AP_DRAGDROP
  120. is the name...  Did you forget, or did that just pass your mind?
  121.  
  122. > For broadcast messages, you have a point, but collecting non-broadcast
  123. > message types is of no relevance.  How many new broadcast message types
  124. > currently exist?  0? 
  125.  
  126. It's nice to follow some standards.  If you want to code for non-broadcast,
  127. that's your choice.  Most of us like to follow a list so they can find out
  128. if they can create WM or WF messages as they wish, without clashing with
  129. other messages.
  130.  
  131. > Not at all.  XBRA doesn't reply on some central list of unique identifiers.
  132. > It relies on programs following a fixed standard.
  133.  
  134. *NOT AT ALL* If two programs use the same XBRA identifier for chaining into
  135. a vector (which is entirely likely), bad things *WILL HAPPEN*. Either the
  136. program would assume it's already installed into the vector (which would not
  137. be the case) or if it tried to unchain from the XBRA chain, it could unchain
  138. the *WRONG PROGRAM*. That's why the XBRA list exists, to make sure things
  139. like this don't happen.
  140.  
  141. The cookie jar is another place where clashes can happen. Of course, you'll
  142. probably say a master cookie list isn't needed either. :-)
  143.  
  144. Of course, if you actually wrote vector sharing programs, you would
  145. understand this.
  146.  
  147. -Ken Hollis
  148. -----------
  149. Subject:  RE: Gem Listing (fwd)
  150.  
  151. > Who said it was difficult?  We're not talking about difficulty.  We were
  152. > talking about system overhead and wasted time.
  153. >
  154. > What's difficult is making a larger-than-1-pixel rectangle so that your
  155. > app doesn't have to be called for every mouse movement, and system time
  156. > doesn't have to be wasted.
  157. The only time this will happen is when the application is topped. If it's
  158. not topped, then a click in one of the windows will send an event to
  159. the app to "wake up".
  160.  
  161. Even so, the overhead is *miniscule*. I've got it in my head to write a
  162. benchmark program to compare overheads of different methods, and put this
  163. argument to rest permanently.
  164.  
  165. -Ken Hollis
  166. ----------
  167. > [...]
  168. > fruitless (since it is a never ending argument). Geneva was specifically 
  169. > designed to meet a set of requirements (small size, excellent user 
  170. > performance, older application compatibility) which are very different 
  171. > than the design specs for MagiC.
  172. Small? 250kb (or so) for GEM patches only, isn't so small.
  173. 192k for a entire ROMable OS is small. :-)
  174.  
  175. Older application compatibility? Ok, here Geneva does fine. However, who
  176. actually wants to run old badly written programs? :-)
  177.  
  178. Also, I take exception to the "excellent user performance" bit. :-)
  179.  
  180. I think that anyone who has taken a look at the internals of Geneva will
  181. be UNimpressed. On the surface it appears nice, but once you start digging
  182. into its internals, you realize that it's actually quite a hack.
  183.  
  184. When a friend and I were digging around with Geneva a couple months ago, this
  185. is what we found:
  186.  
  187. You run one application under Geneva, everything is cool.
  188.  
  189. You run two applications under Geneva, and something interesting happens:
  190.  
  191. The second application is actually running "under" the first application, at
  192. this point they are sharing 50% of the CPU.
  193.  
  194. Envision the application tree like this:
  195.  
  196.                   GEM
  197.                    |
  198.                    v
  199.              Application 1
  200.                    |
  201.                    v
  202.              Application 2
  203.              
  204. Now start up a third application.
  205.  
  206. The third application also runs "under" the first application, and something
  207. interesting happens again: The first application gets 50% CPU, and the
  208. other two get 25% each (regardless of who happens to be "topped").
  209.  
  210. The application tree now looks like this:
  211.  
  212.                    GEM
  213.                     |
  214.                     v
  215.           .-- Application 1 --.
  216.           |                   |
  217.           v                   v
  218.     Application 2       Application 3
  219.  
  220. This means that the applications are getting an uneven share of the CPU.
  221.  
  222. Also if I remember correctly, anything allocated by applications 2 and 3
  223. actually belong to *application 1*. This means Mallocs, file handles, etc.
  224. Nasty.
  225.  
  226. This is how the application tree *should* look:
  227.  
  228.           .------------ GEM --------------.
  229.           |              |                |
  230.           v              v                v
  231.     Application 1   Application 2   Application 3
  232.     
  233. In this case each application would be getting an even amount of CPU time,
  234. and each application would truly own their own memory, handles, etc.
  235.  
  236. I would imagine the reason for all this silliness is that Geneva does not
  237. really replace AES, but simply hooks into it. If it actually replaced the
  238. AES, I doubt any sane person would implement the replacement AES like
  239. Geneva does :-)
  240.  
  241. Geneva also doesn't touch VDI at all, but this is not a problem since things
  242. like NVDI and UIS III continue to work fine. :-)
  243.  
  244. Of course, this was discovered with a beta copy of Geneva, and things could
  245. have changed since then, but I doubt it. :-)
  246.  
  247. -Goemon
  248.  
  249.  
  250.